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REMARKS 

Reconsideration and allowance are requested. The Examiner rejected pending claims 

1-53. No claims have been amended. 

A. Rejection of Claims 1-4, 6-7, 9-17, 19-20, 22-30, 33-39, 41-48 and 50-53 
rejected under 35 U.S.C. §103(a) 

Applicants received the Advisory Action with a further clarification of the Examiner's 

position on the interpretation of the Vrvilo et al. reference. Applicants previous argued that 

Vrvilo et al. does not teach a client/server arrangement but rather a peer-to-peer conferencing 

application and thus one of skill in the art would not have sufficient motivation to combine 

these references. Applicants provide further arguments herein in view of the discussion in 

the Advisory Action that clarifies the Examiner's position regarding the teachings of Vrvilo 

etal. 

The Advisory Action attempts to establish that Vrvilo et al. teach a client/server 
environment but Applicants respectfully maintain that when the arguments are fully analyzed, 
it would be clear to one of skill in the art that Vrvilo et al. fail to teach a client/server network 
environment. The Advisory Action cites col. 42, lines 47 - 65 stating "for the host processor 
within the host system and the APPLICATION PROGRAM as the client and using the local 
monitor for displaying to users." The Advisory Action appears to seek from the citation of 
col. 42 that Vrvilo et al. teach that the host system is a server and the application program is a 
client. Previously, the Examiner had argued that the monitor 106 of Vrvilo et al. was the 
"client" of the computer host processor. However, this position is restated in the Advisory 
Action and the Advisory Action now interprets the conference application that runs on the 
host processor as the client. (Applicants assume that the Examiner has withdrawn the 
interpretation of the monitor as the client to the host processor. Otherwise, the Patent Office 
cannot maintain the confusing position that so many elements taught by Vrvilo et al. are 
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"clients".) In addition, the Advisory Action asserts to "further clarify the issue" by 

explaining that "the client is eventually the application program" citing col. 69, lines 5-38. 

This portion of Vrvilo et al. states: 

The unreliable protocol provides for logical channels and virtualization of the two 
Basic Rate ISDN B-channels. Logical channels are local site entities that are defined 
between the DLM and TII is layer and the client (i.e., application program) using 
them. The logical channels provide the primary mechanism clients use to send 
muhiple data types (e.g., audio, video, data). The layer services muhiplex these data 
types together for transmission to the remote sites. 

In a preferred embodiment, logical channel zero is used as a control channel. Site 
peers (i.e., two conferencing systems in a conferencing session) use this control 
channel to exchange information on their use of other logical channels. Logical 
channels are half-duplex. Therefore, two channels are necessary to send and receive 
data. A priority attribute is associated with a logical channel (and therefore with a data 
type). The unreliable protocol asserts that higher priority data will always be sent 
ahead of lower priority data when both are pending. Priorities are assigned by an API 
call to the TII services. Audio has the highest priority, then data, and last video. 

Although the ISDN Basic Rate Interface (BRI) defines two physical 64 kbit/second B 
channels for data, the services at both DLM and TII virtualize the separate B-channels 
as a single 128 kbit/second channel. Client data types, defined by their logical 
channels, are multiplexed into a single virtual stream on this channel. In a preferred 
embodiment, this inverse multiplexing is accomplished by breaking all packets into an 
even number of fragments and alternating transmission on the two B-channel 
connections. Initially, after channel establishment, the first fragment is sent on the Bl- 
channel, the second on the B2-channel, etc. At the receiving site, fragments are 
collected for reassembly of the packet, (emphasis added) 



Applicants do not dispute that the conference application programs are discussed in 
terms of being "clients" in Vrvilo et al. However, they are not clients in the client/server 
context. The application software is simply a client that communicates data with the 
conference manager services application. FIG. 5 illustrates the point. In FIG. 5, the 
conference manager 544 communicates with several conferencing applications 502 and 504. 
These conferencing applications communicate through the manager and are considered 
"clients" of the software manager. However, there is simply no "server" on Vrvilo et al. The 
Advisory Action alludes to the argument that the host processor 202 of FIG. 2 is the server. 
But that cannot be the case because col. 5, lines 12-29 state that the "audio/video 
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conferencing application 502 running on host processor 202 provides the top-local local 
control of audio and video conferencing between a local conferencing system (i.e., local site 
or endpoint) and a remote conferencing system (i.e. remote site or endpoint). " The data 
conferencing application 504 also runs on the host processor 202. Therefore, the host 
processor running the client application cannot function as a server as the Advisory Action 
hints. Otherwise, you have the illogical conclusion that the "client" software runs on the 
"server" processor. 

Applicants respectfully note that the term "server" is nowhere to be found in the large 
specification of Vrvilo et al. The host processor 202 cannot be a server based on the 
Examiner's own position. In FIG. 1, the conference system A 100 and conference system B 
100 each have conferencing applications (502, 504) that are client software applications to 
their respective conferencing managers 544. FIG. 5 illustrates the system software 
architecture 100 that operates on each conferencing system A and B. In other words, each 
conference system has a host processor that runs the conferencing application and are thus 
each "clients" according to the Examiner's position. This supports Applicants argument that 
these are peer conferencing systems and not client/server networks. Applicants' position that 
these are peer systems communicating with each other is amply supported by Vrvilo et al. 
See, e.g., col. 20, lines 1 - 7 (peer application running on a remote machine); Col. 69, lines 
15-16 (site peers are two conferencing systems in a conferencing session); Col. 9, lines 44 - 
col. 10, lines 44 (multiple references to peer applications during a video call); Col. 22, lines 
10-23 (peer application or peers in a multipoint environment), etc. There are a multitude of 
references within Vrvilo et al. of the peer environment and peer applications communicating 
with each other in a conference setting. There is not a single reference in the 103 pages of 
Vrvilo et al. to a server. There is also no reference to the conferencing applications as clients 
communicating with a server. They only communicate with the conference management 
software - which runs on the same host processor as the conference applications. 
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Accordingly, Applicants respectfully submit that based on the analysis above as well 
as Applicants' previous arguments, that Vrvilo et al. does not teach a client/server network 
environment as would be understood by one of skill in the art. The multitude of references to 
"peer" communications in Vrvilo et al. makes it clear that they do not teach "client and server 
communication" as the Advisory Action asserts. The conference applications (502, 504) are 
merely clients of the conference management software 544 but that concept should not be 
expanded to be interpreted as the reference teaching that they are "clients for the system" as 
the Advisory Action mentions. 

Based on the above arguments. Applicants submit that the other criteria for the 
obviousness combination are not established. For example, given the differences between a 
client/server system and the peer to peer conference system, one of skill in the art would not 
have a reasonable expectation for success. Simply having a desire to improve the quality of a 
display does not provide a reasonable expectation of success given the different structures. 
Applicants also do not acquiesce to the conclusion that even if appropriately combined these 
two references teach all the claim limitations. 

Therefore, Applicants respectfully request that the Examiner reconsider the 
combination of Vrvilo et al. with Goetz. Because Vrvilo et al. fail to teach a client/server 
environment as suggested by the Advisory Action, one of skill in the art by a preponderance 
of the evidence, would not be motivated to combine these references. Therefore, claims 1^, 
6-7, 9-17, 19-20, 22-30, 33-39, 41-48 and 50-53 are patentable and in condition for 
allowance. 

Claims 2-13 depend from claim 1 and recite further limitations therefrom. 
Accordingly claims 2-13 are also patentable over the cited art. 

Independent claim 14 and its dependent claims 15-26 are also patentable as well as 
independent claim 27 with its dependent claims 28-35, as well as independent claim 36 and 
dependents claims 37-45, and independent claim 46 and its dependent claims 47-53. 
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CONCLUSION 

Having addressed the rejection of claims 1 -53, Applicants respectfully submit that the 
subject application is in condition for allowance and a Notice to that effect is earnestly 
solicited. 

Respectfully submitted. 



Date: June 23, 2006 

Correspondence Address: 
Thomas Restaino 
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By: /Thomas M. Isaacson/ 
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Attorney for Applicants 
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